Please don't directly assign qs which is a function parameters in API.
This will cause error if user pass read only object as option.

Thanks @AtkinsChang. Did this break something that used to work? We've been assigning to qs like this for a few months now so perhaps it is not just the assignment if you've used any of those versions.

which is a function parameters in API

I'm sorry, I don't get what you mean here. Can you give a clear example?

@JonKrone
For example, in src/files/add.js:voptions is passed directly to createAddStream({ qs: options }).
In src/utils/send-files-stream:
line 34 options = options ? Object.assign({}, options, options.qs) : {}
line 76 const qs = options.qs || {}
So basically the qs is the options user pass to the api.

Because of line 34 like you mention, it looks like qs here is actually a copy of the options passed. I think that this avoids problems with a read-only options object. For example, the below doesn't cause any problems:

const obj = {}
Object.defineProperty(obj, 'color', {
  writable: false,
  value: 'red'
})
const options = Object.assign({}, obj)
options.color= 'rouge'
console.log(options.color) // prints 'rouge'

Did this break something that worked for you before?

Yes this is the currently workaround I use.
But I think the internal ipfs api should use a copy of user's option instead of modifying it directly. It is a good practice to avoid reassigning function arguments, which may cause user hard to debug in some situation, for example: shared options between different apis.

@AtkinsChang ipfs-api internally does use a copy of the user's options because of line 34 and does not mutate the options you pass in. Given that, I'm not sure this is the source of the problem you were having.

If you can reproduce it in some code please let me know or submit a PR with your proposed changes.